1. Field of the Invention
The present invention relates to a method and system for accessing a peripheral memory device and, more particularly, to a method and system that allows a host computing device (e.g., server computer) to directly access a peripheral memory device without the assistance of an external processor.
2. Description of the Related Art
Host bus adapters (HBAs) are well-known peripheral devices that handle data input/output (I/O) operations for host devices and systems (e.g., servers). In simple terms, a HBA provides I/O processing and physical connectivity between a host device and external data storage devices. The external storage devices may be connected using a variety of known “direct attached” or storage networking technologies, including Fiber channel, iSCSI, VI/IP, FICON, or SCSI. HBAs provide critical server CPU off-load, freeing servers to perform application processing. HBAs also provide a critical link between storage area networks (SANs) and the operating system and application software residing within the server. In this role the HBA enables a range of high-availability and storage management capabilities, including load balancing, SAN administration, and storage management.
FIG. 1 illustrates a block diagram of a host system 10, which includes a conventional host server 12 that executes application programs 14 in accordance with an operating system program 16. The server 12 also includes necessary driver software 18 for communicating with peripheral devices. The server 12 further includes conventional hardware components 20 such as a CPU (not shown), host memory (e.g., ROM or hard disk drive) (not shown), RAM (not shown), cache (not shown), etc., which are well known in the art.
The server 12 communicates via a peripheral component interconnect (PCI or PCIX) bus interface 22 to a HBA 24, which handles the I/O operations for transmitting and receiving data to and from remote fiber channel disk storage devices 28 via a fiber channel fabric 26. Other host systems 30 may also be “connected” to the fiber channel fabric 26 via respective HBAs 32 in a similar fashion. The server 12 may communicate with other devices 36 and/or clients or users (not shown) via an Ethernet port/interface 38, for example, which can communicate data and information in accordance with well-known Ethernet protocols. Various other types of communication ports, interfaces and protocols are also known in the art that may be utilized by the server 12. The server 12 may also be connected to the Internet 40 via communication port/interface 38 so that remote computers (not shown) can communicate with the server 12 using well-known TCP/IP protocols. Additionally, the server 12 may be connected to local area networks (LANs) (not shown) and/or wide area networks (WANs) (not shown) in accordance with known computer networking techniques and protocols.
FIG. 2 is a block diagram illustrating some core components of a conventional HBA card 24. The HBA 24 includes a plurality of contact pins or slides 25 for making electrical contact to corresponding pins or slides in a PCI or PCIX bus slot (not shown) located on the PCI(X) bus interface 22 (FIG. 1), thereby allowing the server 12 (FIG. 1) to communicate with the HBA 24. The HBA 24 further includes a controller circuit 50 that includes a microprocessor 52 for executing program instructions and processing data stored in volatile memory 54. The HBA card 24 also includes a fiber channel connector/port 54 for establishing a communication link to the fiber channel fabric 26.
In conventional systems, typically, the microprocessor 52 is responsible for operations such as direct memory accesses between the host memory and the HBA. The HBA controls data transfers to and from system memory (e.g., FC Disk 28) without the need for host CPU involvement. Additionally, the microprocessor 52 is responsible for handling other I/O data management and processing operations such as processing context information for each frame of data, routing data to appropriate storage devices 28, etc. These types of functions by the microprocessor 52 and HBA 24 are well-known in the art.
The executable program(s) and data (collectively referred to herein as the “program image”) necessary for the microprocessor 52 to perform its various I/O management and handling operations is stored in a nonvolatile memory 56 (e.g., flash memory 56). This program image, or at least portions thereof, is downloaded on an as needed basis from the flash 56, via flash interface device 58 and a flash interface bus 60, to the volatile memory 54 and/or microprocessor 52 cache (not shown) for faster execution and processing by the microprocessor 52.
During normal operation, in order to access (read or write) the flash memory 56, during a host or HBA wake-up process, for example, the microprocessor 52 writes to and sets dedicated registers 62 (referred to herein as μp registers 62) allocated for this purpose. As explained in further detail below with respect to FIG. 5A, the μp registers 62 typically include a read-address register 62a (FIG. 5A), a read-data register 62b, a read-next-data register 62c, a write-address register 62d, a write-data register 62e, and a control/status register 62f. The operation of these registers during access of flash memory is discussed in further detail below.
FIG. 3 illustrates a block diagram of some of the core components or modules of a program image that are downloaded from flash memory 56 to volatile memory 54. As shown in FIG. 3, the program image includes a kernel program or module 70, which is the core or minimum instruction set for the microprocessor 52 to operate and execute other instructions and functions. Such kernel programs are well-known in the art. A basic input/output system (BIOS) program 72 is also stored within the volatile memory 54 for performing HBA component configuration and initialization operations at system start up or wake up. Such BIOS programs are also well-known in the art. The program image further includes a status and error program 74 for monitoring the status of microprocessor 52 operations and reporting an error signal if an error occurs. Such status and error programs are also well-known in the art. The program image also includes one or more executable programs 76 and data 78 for performing its I/O operations as discussed above.
The diagram in FIG. 3 illustrates that different areas of the flash hold different kinds of contents. Generally, there are two types of accesses to flash memory—automatic and programmed. Automatic accesses are carried out because the requesting device needs the information to be functional. In particular, the microprocessor must read instructions from the flash device directly into its instruction-processing pipeline (not copied to any other memory) when it starts processing upon system start up or after a reset is cleared. The “kernel” area contains these instructions. This design relies on information contained in the non-volatile memory to provide a wake-up program for the microprocessor. In a multi-channel HBA, the microprocessor in one channel may be reset and restarted independently of the other microprocessor(s).
The “BIOS” area has another type of automatic access. The host system (server) reads from the flash across the PCI/X bus a program that extends its built-in wake-up program. The program is tailored to the HBA to allow the host system to use the HBA I/O facilities to “boot up,” that is, to read extensive control programs from a large external data source. Without this non-volatile “Expansion ROM” the HBA is useless to the host system until the entire host system OS becomes active by booting up over a different external access facility. These automatic direct host-to-flash accesses are known in the art as host ROM base address register (BAR), or ROM BAR, accesses. One disadvantage of host ROM BAR accesses, as discussed in further detail below, is that during these accesses the PCI/X bus is “locked” until the ROM BAR access request is completely satisfied.
The second type of access is a programmed access. In contrast to “automatic” accesses, described above, programmed accesses retrieve data for various uses in accordance with various application programs. Additionally, these programmed accesses can wait (allowing the requesting device to do other things in the interim) on data availability and is, therefore, not “locked” during a pending access request. In prior art systems, programmed accesses were performed by either the HBA microprocessor 52 or the host system, via the PCI/X bus 22, with the assistance by the HBA microprocessor 52.
Typically, during manufacture of the HBA card 24, the program image is “burned” into or programmed into the nonvolatile flash memory 56, before it is implemented on the HBA card 24. Occasionally, an error will occur during programming of the program image such that the microprocessor 52 will not be able to function properly, if at all. Such an error is typically detected during testing of the HBA 24 after it has been assembled. If the error involves the kernel program 70 of the program image, the microprocessor 52 will not function at all and will not be able to assist in reprogramming the flash memory 56. In such an instance, the flash memory 56 must be removed from the HBA card 24 and reprogrammed.
Additionally, even if the kernel program 70 was successfully copied into the flash memory 56, if significant errors occur in programming the other programs 72, 74, 76 and/or 78 into the flash memory 56, the microprocessor 52 will not operate properly. In these instances, as well, the flash memory 56 must be removed from the HBA card 24 and reprogrammed.
Sometimes, one or more programs and/or data of the program image stored in the flash memory 56 can become corrupted during operation of the HBA 24 “in the field” (i.e., during operation within a host system) due to external forces or factors (e.g., power failure during reprogramming of flash 56). In such circumstances, the microprocessor 52 will not operate properly and there is no way to reprogram the flash 56 so as to replace the corrupted program image, except by going out into the field and removing the HBA card 24 from its host system and reprogramming the flash memory 56 with a new program image.
Thus, in prior art systems, reprogramming of the nonvolatile memory 56 if the program image is bad (corrupted) requires a service technician or engineer to remove the nonvolatile memory 56 from the HBA 26 and, if the HBA 24 has been implemented in the field, to travel where the HBA 24 is located in order to reprogram the memory 56 and fix the problem. This is an inefficient process that unnecessarily wastes valuable human resources. Thus, there is a need for a method and system that allows a host device to perform direct and programmed accesses to the nonvolatile memory so as to be able to reprogram the nonvolatile memory within a HBA, without intervention and assistance from the microprocessor on the HBA.
Additionally, direct programmed access by a host device to nonvolatile memory without the assistance of the HBA microprocessor 52 can further increase the multi-tasking and efficiency of the overall system. As mentioned above, prior art automatic direct accesses by the host device during host “boot up” locked the PCI/X bus 22 until the access request was completely satisfied. However, the locking of the PCI/X bus during a programmed access by the Host is not efficient from a multi-tasking perspective. Therefore, the mechanism for performing automatic direct accesses by the host is not well-suited for performing direct programmed accesses by the host when multiple application programs running on the host desire access to the PCI/X bus 22. Therefore, for direct programmed accesses by the host it is desirable to provide registered (or buffered) read and/or write operations so that the PCI/X bus 22 can be free for other applications and requests, during a pending direct access to the nonvolatile memory.